Generic Monitoring Packet Handling Mechanism for OpenFlow 1.1

ABSTRACT

A method implemented by a network element monitor OpenFlow data flows and enable operations, administration and management (OAM) functionality in OpenFlow. The method inserts OpenFlow OAM packets into an OpenFlow data flow to monitor the OpenFlow data flow, wherein inserted OpenFlow OAM packets have fate sharing with data packets in the OpenFlow data flow. The method comprises the steps of receiving by the network element the OpenFlow OAM packets from a source through a port of the network element, matching by an OpenFlow switch module using a matching structure of OpenFlow data packets received by the network element to identify the OpenFlow OAM packets, and forwarding the identified OpenFlow OAM packets to a flow table or group table of the OpenFlow switch module to aggregate the OpenFlow OAM packets with a corresponding OpenFlow data flow.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority from U.S. provisional patentapplication 61/504,267 titled GENERIC MONITORING PACKET HANDLINGMECHANISM FOR OPENFLOW 1.1, filed Jul. 4, 2011.

FIELD OF THE INVENTION

The embodiments of the invention are related to the implementation ofoperations, administration and management (OAM) functions for OpenFlow.Specifically, the embodiments of the invention relate to a method andsystem for identifying, inserting and de-multiplexing OpenFlow OAMpackets while ensuring fate sharing for these OpenFlow OAM packets inrelation to the monitored OpenFlow data flows.

BACKGROUND

Unlike the traditional network architecture, which integrates both theforwarding (data) and the control planes in the same box (networkelement), a split architecture network decouples these two planes andexecutes the control plane on servers that might be in differentphysical locations from the forwarding elements (switches). The use of asplit architecture in a network enables the simplification of theswitches implementing the forwarding plane and shifts the intelligenceof the network into a number of controllers that oversee the switches.

The tight coupling of the forwarding and control planes in a traditionalarchitecture usually results in an overly complicated control plane andcomplex network management. This is known to create a large burden andhigh barrier to new protocols and technology developments. Despite therapid improvement of line speeds, port densities, and performance, thenetwork control plane mechanisms have advanced at a much slower pacethan the forwarding plane mechanisms.

In a split architecture network, controllers collect information fromswitches, and compute and distribute the appropriate forwardingdecisions to switches. Controllers and switches use a protocol tocommunicate and exchange information. An example of such protocol isOpenFlow (see www.openflow.org), which provides an open and standardmethod for a switch to communicate with a controller, and it has drawnsignificant interest from both academics and industry.

SUMMARY

A method implemented by a network element monitor OpenFlow data flowsand enable operations, administration and management (OAM) functionalityin OpenFlow. The method inserts OpenFlow OAM packets into an OpenFlowdata flow to monitor the OpenFlow data flow, wherein inserted OpenFlowOAM packets have fate sharing with data packets in the OpenFlow dataflow. The method comprises the steps of receiving by the network elementthe OpenFlow OAM packets from a source through a port of the networkelement matching by an OpenFlow switch module using a matching structureof OpenFlow data packets received by the network element to identify theOpenFlow OAM packets, and forwarding the identified OpenFlow OAM packetsto a flow table or group table of the OpenFlow switch module toaggregate the OpenFlow OAM packets with a corresponding OpenFlow dataflow.

A network element monitors OpenFlow data flows and enable operations,administration and management (OAM) functionality in OpenFlow. Thenetwork element to insert OpenFlow OAM packets into an OpenFlow dataflow to monitor the OpenFlow data flow wherein inserted OpenFlow OAMpackets have fate sharing with data packets in the OpenFlow data flow.The network element comprising an incoming physical port to receiveOpenFlow data packets from a source node over a first networkconnection, an outgoing physical port to transmit OpenFlow data packetsto a destination node over a second network connection, a networkprocessor connected to the incoming physical port and the outgoingphysical port, the network processor executing an OpenFlow switchmodule. The OpenFlow switch module to match a matching structure inOpenFlow data packets to identify the OpenFlow OAM packets, to forwardthe identified OpenFlow OAM packets to a flow table or group table ofthe OpenFlow switch module to aggregate the OpenFlow OAM packets with acorresponding OpenFlow data flow, and to forward the OpenFlow data flowto the destination node through the outgoing physical port.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings in which likereferences indicate similar elements. It should be noted that differentreferences to “an” or “one” embodiment in this disclosure are notnecessarily to the same embodiment, and such references mean at leastone. Further, when a particular feature, structure, or characteristic isdescribed in connection with an embodiment, it is submitted that it iswithin the knowledge of one skilled in the art to affect such feature,structure, or characteristic in connection with other embodimentswhether or not explicitly described.

FIG. 1 is a diagram of one embodiment of an example architecture for asimple OpenFlow network.

FIG. 2 is a diagram of one embodiment of a network element executing ageneric packet monitoring mechanism and process.

FIG. 3A is a diagram of a first embodiment of an OpenFlow switch module.

FIG. 3B is a diagram of a second embodiment of an OpenFlow switchmodule.

FIG. 4 is a diagram of a Openflow matching structure.

FIG. 5 is a diagram of one embodiment of a controller to switch OpenFlowmessage format FIG. 6 is a diagram of one embodiment of an injectionaction format.

FIG. 7A is a flowchart of one embodiment of a process for inserting anOpenFlow OAM packet by the OpenFlow switch module.

FIG. 7B is a flowchart of one embodiment of a process for preparing anOpenFlow OAM packet by a virtual port of the network element.

FIG. 8 is a flowchart of one embodiment of a process for de-multiplexing

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth.However, it is understood that embodiments of the invention may bepracticed without these specific details. In other instances, well-knowncircuits, structures and techniques have not been shown in detail inorder not to obscure the understanding of this description. It will beappreciated, however, by one skilled in the art, that the invention maybe practiced without such specific details. Those of ordinary skill inthe art, with the included descriptions, will be able to implementappropriate functionality without undue experimentation.

The techniques shown in the figures can be implemented using code anddata stored and executed on one or more electronic devices (e.g., an endstation, a network element, server or similar electronic devices). Suchelectronic devices store and communicate (internally and/or with otherelectronic devices over a network) code and data using non-transitorymachine-readable or computer-readable media, such as non-transitorymachine-readable or computer-readable storage media (e.g., magneticdisks; optical disks; random access memory; read only memory; flashmemory devices; and phase-change memory). In addition, such electronicdevices typically include a set of one or more processors coupled to oneor more other components, such as one or more storage devices, userinput/output devices (e.g., a keyboard, a touch screen, and/or adisplay), and network connections. The coupling of the set of processorsand other components is typically through one or more busses and bridges(also termed as bus controllers). The storage devices represent one ormore non-transitory machine-readable or computer-readable storage mediaand non-transitory machine-readable or computer-readable communicationmedia. Thus, the storage device of a given electronic device typicallystores code and/or data for execution on the set of one or moreprocessors of that electronic device. Of course, one or more parts of anembodiment of the invention may be implemented using differentcombinations of software, firmware, and/or hardware.

As used herein, a network element (e.g., a router, switch, bridge, orsimilar networking device.) is a piece of networking equipment,including hardware and software that communicatively interconnects otherequipment on the network (e.g., other network elements, end stations, orsimilar networking devices). Some network elements are “multipleservices network elements” that provide support for multiple networkingfunctions (e.g., routing, bridging, switching, Layer 2 aggregation,session border control, multicasting, and/or subscriber management),and/or provide support for multiple application services (e.g., datacollection).

In the following description and claims, the terms ‘coupled’ and‘connected,’ along with their derivatives, may be used. It should beunderstood that these terms are not intended as synonyms for each other.‘Coupled’ is used to indicate that two or more elements, which may ormay not be in direct physical or electrical contact with each other,co-operate or interact with each other. ‘Connected’ is used to indicatethe establishment of communication between two or more elements that arecoupled with each other.

The embodiments of the invention provide a method and system foravoiding the disadvantages of the prior art. Most data planetechnologies, such as Ethernet or multi-protocol label switching (MPLS),used in combination with OpenFlow have defined OAM solutions that arespecific to these technologies. The OAM solutions defined by these dataplane technologies provide a mechanism to identify, inject, andde-multiplex the OAM packets into/from a data flow. Also these OAMsolutions ensure correct fate sharing for OAM packets where the OAMpackets are forwarded in the same manner that the service packets areforwarded through a network. However, OpenFlow does not provide supportfor any mechanism that enables OAM packet identification, injecting orde-multiplexing. This makes the implementation of any OAM solution in anOpenFlow domain impossible. Implementing fate sharing for an OAMtechnology to be used in OpenFlow requires special consideration aboutthe identification of OAM packets that is not supported by the OpenFlow1.1 specification.

The embodiments of the invention overcome these disadvantages of theprior art. The embodiments of the invention. The embodiments of theinvention provide a process and systems for enabling OAM packets (i.e.,tagged frames) to be inserted into an OpenFlow data flow, and to bede-multiplexed from the OpenFlow data flow. The process and systemsupport fate sharing for the OpenFlow OAM packets that ensures theOpenFlow OAM packets take the same path through a network between thesource and destination of the data flow as the other data packets of thedata flow (i.e., data stream). To distinguish the OpenFlow OAM packets(i.e., tagged frames) from other OpenFlow data packets a matching fieldthat is not taken into account during matching for the handling of theOpenFlow data packets is utilized to identify the OAM packets. Anon-allocated value of the selected field's domain is used to identifythe OAM packets (tagged frames). To insert the OAM packets (taggedframes) into any stage of the packet processing pipeline, a new logicalmodule is added to the OpenFlow switch module. The new logical module isreferred to herein as the ‘Packet Inject Logic’ (PIL). Two exampleimplementation options are described herein. In the first exampleimplementation, the PIL is configured to manage the injection of the OAMpackets (tagged frames) on per-packet basis; in the second exampleembodiment, the PIL receives instructions directing the injection of theOAM packet (tagged frame) from other switch modules of the networkelement through meta data attached to the OAM packet. In other exampleembodiments, the de-multiplex process distinguishes between the OpenFlowdata packets and the OpenFlow OAM packets (tagged frames) using anin-switch and/or a controller termination option. The OpenFlow protocolis extended in order to support the remote instruction of the PILrelated to the identification, injection and de-multiplexing of theOpenFlow OAM packets.

OpenFlow Architecture

FIG. 1 is a diagram showing an overview of the OpenFlow interfacebetween a switch and a controller. OpenFlow defines a logical switchmodel, which includes defining packet forwarding and processingfunctions of the logical switch making use of a generic table-basedmodel in the form of a flow table to create a packet processingpipeline. The tables defined in this table model comprise rows whereeach row describes a packet handling alternative with three fields:rules, actions and counters. The rules specify the circumstances underwhich the actions are to be executed. In each instance where the actionsare applied, the corresponding counter is updated.

In the OpenFlow 1.1 specification, two table types, the flow table andthe group table, have been defined. In a flow table the rule fieldcontains a vector of attributes from the header. This vector containsvariables of the Ethernet, the MPLS, the IP and the TCP/UDP headers. Therule of the group table is an index identifying the action in a list ofactions to be executed for the packet. The group table thereby supportscomplex actions such as multicast and protection.

The packet processing pipeline is formed by a sequence of flow tablesfollowed by one group table. Any packet entering the switch isautomatically processed according to the first flow table. As a resultof matching the packet in the first flow table, the packet can beupdated, sent out through a port or sent for further processing to asubsequent table. Meta data can be assigned to the packet duringprocessing in each flow table and passed to the subsequent tables. Ifthe packet is sent to a subsequent table, it will then be processedaccording to that flow table. The packet can be processed by each tablein the pipeline or can be forwarded to a port or any particular table inthe pipeline thereby bypassing processing of intermediate tables.

The final table in the packet processing pipeline is the group table.The group table consists of group entries. The ability for packets in aparticular data flow (i.e. a particular flow) to point to a groupenables OpenFlow to represent additional methods of forwarding thepackets of that flow (e.g. select, all, fast failover, and similaractions). There are Action Buckets associated with a group table entry,where each action bucket contains a set of actions to execute. The grouptable entry determines which Action Bucket to execute, where thepossible actions are similar to those defined in the flow tables.

The de-coupled control platform of the split architecture eases the taskof modifying the network control logic and provides a programmaticinterface upon which developers can build a wide variety of newprotocols and management applications. In this model, the data andcontrol planes can evolve and scale independently, while the cost of thedata plane elements is reduced.

Network Element Architecture

The embodiments of the invention are implemented in a network elementsuch as a router or switch in a wide area network, such as the Internet,or similar network. An example network element is illustrated in FIG. 2.The network element 201 can include a network processor 203 thatprocesses packets received from incoming physical ports 221 andtransmitted by the outgoing physical ports 223, which each connect thenetwork element to a network or set of networks. A ‘set,’ as used hereinrefers to any positive whole number of items including one item.

The incoming physical ports 221 and outgoing physical ports 223 managephysical and link level data processing. The incoming physical ports 221handle incoming data traffic at the physical and link level by framingor similarly processing the incoming signal and providing this data tothe network processor 203 for further processing. Similarly, theoutgoing physical ports 223 handle outgoing data traffic at the physicaland link level by deframing or similar processing to transmit it toother devices over a connected network. These two sets of ports functiontogether to enable communication with any number of other devices over anetwork using any number or combination of links.

The network processor 203 can include a set of switch modules, virtualports and protocol agents amongst other components. Those componentsrelevant to understanding the OpenFlow OAM process are illustrated anddiscussed while other components are omitted for sake of clarity. Theswitch modules can include non-OpenFlow switch modules 205 and OpenFlowswitch modules 209. Non-OpenFlow switch modules 205 can be any number ofmodules dedicated to processing the forwarding and handling of datapackets, including e.g., the creation or termination of OAM frames. TheOpenFlow switch module 209 is described herein in further detail inregard to FIGS. 3A and 3B. The OpenFlow switch module 209 implements theflow table and manages the forwarding and processing of all OpenFlowdata packets.

The OpenFlow protocol agent 207 manages the communication between thenetwork element 201 and the controller. The OpenFlow protocol agent 207processes the OpenFlow control messages received from the OpenFlowcontroller and generates OpenFlow messages to the controller as needed.The OpenFlow protocol agent 207 can include support for receivingconfiguration messages to insert OAM packets into a data flow and caninclude support for sending received OAM packets to the OpenFlowcontroller for processing.

In one embodiment, the virtual ports 211A and 211B can optionallyprovide a pre-processing of OAM packets received by the network element201. OAM packets can be directed to these virtual ports to process andupdate the meta data of these OAM packets. In one embodiment, OAMpackets can be directed to these virtual ports by sources of the OAMpackets in which case the meta data of the OAM packets is updated by theport as directed by the source to ensure proper forwarding or processingby the OpenFlow switch module.

In another embodiment, the virtual ports 211A and 211B modify or updatethe meta data in a manner specific to that virtual port. In thisembodiment, the sources of the OAM packets direct the OAM packets to thevirtual ports so that they will be processed in the manner known forthat virtual port.

Packet Identification

The embodiments of the invention describe a generic configuration methodfor identifying certain packets of an OpenFlow data flow in an OpenFlowswitch, which allows the identification of those packets and ensures thefate sharing with packets belonging to the data flow.

To identify specific packets, such as OAM packets in an OpenFlow dataflow, the embodiments of the invention utilize fields in the OpenFlowdata packets that are not utilized during matching (i.e., not consideredwhen determining how a data packet is to be forwarded across a network).Such fields are referred to as wildcard or wildcarded fields. Thesefields can be used to distinguish a certain packet from the other datapackets in a data flow by an OpenFlow switch. Any number or combinationof these fields of the OpenFlow packets can be selected as a matchingfield so long as they are not taken into account in identifying the dataflow or for making forwarding decisions. The value used to identify theOAM packets when placed in the selected matching field's domain can beany value that is not used by any valid data packet.

FIG. 4 is a diagram of an example OpenFlow matching structureencompassing a data packet or data frame. In the illustrated examplewildcard sections and fields can be used to identifying certain packets(referred to as tagged packets) in the example cases of an Ethernetand/or an IP flow. Note these examples do not preclude the use of otherfields, for example priority fields can be also used for tagging.

Packet Injection

In one embodiment, any OpenFlow switch that is directed by its OpenFlowcontroller or other source to inject packets (referred to as taggedpackets) such as OAM packets into a data flow is dealing with packets tobe injected that are generated by an entity (i.e., source) that may notbe a part of the OpenFlow forwarding mechanism. Such an entity can befor instance an external OAM module attached to the switch (e.g., anon-OpenFlow switch module 205) or the OpenFlow controller. The taggedpackets generated by such entities can be received by the OpenFlowswitch module through virtual ports. In one embodiment, any packetsentering the OpenFlow switch module through a physical or virtual portmust be sent through the whole packet processing pipeline.

FIGS. 3A and 3B are diagrams of two example embodiments of theprocessing, injection and detecting of the OpenFlow OAM packets in anOpenFlow switch module. The processes implemented by these exampleOpenFlow switch modules each start with the initial processing of thedata flows at the first flow table. In one example configurationillustrated in FIG. 3A, the data packets of different smaller flows canbe aggregated into a common larger flow. A flow entry will be defined inthe flow tables for each smaller flow; the actions of these entries willdirect the update of the data packets to fit them into the newaggregated flow. A second flow entry can be deployed in a subsequenttable that will describe the common flow.

The example embodiments of the invention adds a new module, the PacketInject Logic (PIL) 301, to the OpenFlow switch module 109 and places itin front of the packet processing pipeline. The PIL 301 checks the metadata associated with each received data packet or the content of thedata packet to determine whether to send the data packet through thedefault processing pipeline starting with the first table after the PIL301 or to insert the data packet into a subsequent flow table in thepipeline. In this latter case the PIL 301 can also define meta data(i.e., write meta data to the data packet) that can be considered duringmatching in the subsequent tables.

In the first example embodiment in FIG. 3A, the PIL 301 utilizes theextensible matching capability of OpenFlow 1.1 to implement a PILanalysis based data packet handling process. The PIL module 301 isimplemented by the first flow table and the other flow tables areshifted to the next subsequent flow table. For instance the first flowtable is actually implemented by the second flow table, and so on. Thematching performed by each flow table examines the meta data providedtogether with the packet data and/or the header fields of the datapacket can be considered. In this latter case, a new matching type canbe defined if the standard matching types cannot match on the desiredpacket fields. In this example PIL analysis embodiment, the new PILmatching table 303 lists all packets that should be inserted into laterpipeline stages while the default action for that table (i.e., what todo with non-matching packets) is to send these non-matching packets tothe next table.

In the second example embodiment illustrated in FIG. 3B, the PIL module301 implements a meta data directed data packet handling process. ThePIL module 301 receives the meta data passed together with the datapacket, where this meta data explicitly determines at what pipelinestage the packet must be included into the common data flow. In thisembodiment, the PIL module 301 reads the meta data of each data packetand passes the data packet to the proper flow table or to the grouptable to join the data packet to the common flow. In this example metadata directed packet handling embodiment, the meta data or packet datacan include any number of attributes such as an attribute that is (1)the identifier of the flow table (0-255 according to OpenFlow 1.1) towhich the data packet is to be forwarded. In the case when the packet issent directly to the Group Table, then the attribute can be (2) thetable ID set to a value out of the flow table id domain (e.g., 256 incase of OpenFlow 1.1). Other attributes can include (3) the Group IDwhere the table ID can be set to the Group Table constant otherwise itmay not be considered) and other (4) meta data to be used duringmatching.

To realize the first example PIL analysis based embodiment illustratedin FIG. 3A, the content of the OpenFlow OAM packets (tagged packets) isutilized (i.e., used for matching) to determine how the OAM packet is tobe handled. In the case of OAM packets, the content of the OAM packetmust be checked (for instance MEP IDs) to select the appropriate tableor group. To match on these fields the OpenFlow switch module canimplement a new matching type. Furthermore, these new matching types arespecific to the type of the tagged packet. In some limited scenarios,the current switch implementation can support the packet injectionwithout any significant hardware updates. Rather, the functionalitydescribed herein can be partly or wholly implemented in softwareconfiguration by configuring the OpenFlow switch module 109 to shift thestandard flow table processing and insert the PIL into the first flowtable.

In the second meta data directed implementation illustrated in FIG. 3B,extensions to the OpenFlow switch module 109 are necessary. However,these extensions are not solution specific. Since the decision on whatto do with the packet is actually determined by a module external to theOpenFlow switch module the changes to the OpenFlow switch module toinclude the PIL module 301 can be generic to all scenarios.

In regard to the OpenFlow switch module 109 configuration, the first PILanalysis based embodiment of FIG. 3A requires continually maintainingand configuring the first table (i.e., the PIL module 301). To insert anew class of tagged packet in PIL module 301, the first table must beextended with appropriate flow rules to match and handle the new classof tagged packet. In the second meta data directed implementation ofFIG. 3B, there is no need to do continual configuration management.

Virtual Ports

Both implementations illustrated in FIGS. 3A and 3B assume that someinformation is provided and attached as meta data to the data packetbeing processed by the PLI, where this meta data is provided or attachedby the physical or virtual port from which the data packet is receivedby the OpenFlow switch module. In one embodiment, the physical and orvirtual ports are extended such that the ports shall be able to passmeta data along with the data packet to the OpenFlow switch module andthe PIL in the OpenFlow switch model is be able to interpret thereceived meta data during packet processing. Depending on the source ofsuch information placed into the meta data by the physical port orvirtual port two alternative embodiments are differentiated an externalsource embodiment and an internal definition embodiment.

In an external source embodiment, the meta data is generated by thesource of the packet, e.g., the OpenFlow controller. In this case avirtual port copies the meta data provided by the source into the metadata of the data packet to be passed to the OpenFlow switch module. Thisexternal source embodiment does not require any configuration updates ofexisting OpenFlow virtual port configuration procedures.

In the internal definition embodiment, the meta data for a data packetis generated by the virtual port itself. In this embodiment, thegranularity of the definition of the meta data is tied to the receivingvirtual port, i.e., all packets from the same virtual port will betreated in the same way; each of the data packets will be given the samemeta data and as a result will be injected by the PIL into the samestage of the pipeline. The configuration of these virtual ports can be aspecialized process or protocol managed by the OpenFlow controller.

In regard to the handling of OAM packets, the OpenFlow controller is onesource of the OAM (tagged) packets. For instance the OpenFlow controllermay want to check whether an OpenFlow data flow is configuredappropriately. If the system utilizes the meta data directed packethandling embodiment, then the source of the data packet must provide themeta data, as well. To make the OpenFlow controller fulfill thisrequirement, the OpenFlow protocol can be extended as described hereinbelow.

OpenFlow Message Option for Controller Generated Tagged Packets

A new OpenFlow message option defines a new OpenFlowcontroller-to-switch message comprising the following fields: (1) acommon OpenFlow header, which encodes the OpenFlow protocol version, thetype and the length of the message and a transaction identifier; (2) anidentifier of the incoming port, which is considered during matching asin_port; (3) a start table index, where the packet is injected, whichcan be set either to a valid table index or to a GROUP_TABLE constant;(4) a group identifier, which is valid if a start table index is set toa GROUP_TABLE constant, otherwise, it must be set to 0 by the controllerand must be ignored by the switch; (5) meta data to be used duringmatching and (6) the OAM packet to be inserted. An example layout ofthis message is illustrated in FIG. 5.

The GROUP_TABLE constant must be outside of the valid flow table indexedto avoid collision. In OpenFlow 1.1, the flow tables are indexed from 0to 255. So the GROUP_TABLE can be any value larger than 255.

OpenFlow Action Option for Controller Generated Tagged Packets

The embodiments of the invention define a new action for use inimplementing the monitoring of OpenFlow flows and other OAM function.This action option can make use of the existing Packet Out messagespecified by the OpenFlow 1.1 standard. According to the standard, thePacket Out message can instruct the OpenFlow switch to send a packetthrough the processing pipeline by including an OFPAT_OUTPUT commandwhere the out port is set to OFPP_TABLE virtual port. However, thecommand only expresses that the packet must be sent through the pipelinebut does not enable specifying at which stage in the processing pipelineof the OpenFlow switch module to insert it. This embodiment defines anew action that is referred to herein as an OFPAT_INJECT_PACKET, whichcomprises the following fields: (1) a table index encoding the flowtable index or an indicator that the group table is to be utilized(through GROUP TABLE constant); (2) a group entry identifier identifyinga group table entry if the table index is set to the GROUP_TABLEconstant, otherwise this value is set to null and must be ignored by thePIL of the OpenFlow switch module; and (3) a meta data field to be usedduring packet processing (i.e., matching) in the processing pipeline. Anexample layout of the action is illustrated in FIG. 6.

To inject a tagged packet (e.g., an OAM packet) into the processingpipeline by the controller, the Packet Out message can include anOFPAT_INJECT_PACKET action in its action field and not an OFPAT_OUTPUTaction.

FIGS. 7A and 7B are flowcharts of one embodiment of the processes of thePIL module and the virtual port, respectively, implementing the packetinjection process and system described herein above. In regard to thePIL module, the process as illustrated in FIG. 7A, is initiated inresponse to receiving a data packet from the physical or virtual port(Block 701). The PIL module examines each incoming packet by usingeither the PIL analysis based packet handling or meta data directedpacket handling. In either case the PIL matches packet data to identifypackets for monitoring data flows such as OAM packets and to determinewhich of the packet processing pipeline stages to forward the datapacket to implement the insertion of the data packet into the commondata flow (Block 703). In the PIL analysis based process, the PIL moduleidentifies the pipeline stage based on matching rules that can includeany field of the data packet, the entire matching structure as describedabove or any combination or sub-combination thereof. The matchingincludes a match on the packet including a tag identifying the datapacket as an OAM packet or similar packet for monitoring data flows. Inthe meta data directed analysis, the matching rule identifies the OAMpackets based on the tag, but then primarily identifies the pipelinestage for forwarding based on the meta data identification of the stagethat has been defined by the port through which the OpenFlow switchreceived the data packet. Data packets that are not tagged are forwardedto a default pipeline stage, which is typically the next stage in thepipeline.

In some embodiments, before forwarding the data packet to the determinedpipeline stage, an action of the PIL module correlated with the matchingrule can be executed to update the meta data of the data packet (Block705). The update of the meta data can influence the processing of thedata packet in the pipeline stage to which it is being forwarded. Afterthe meta data is updated the data packet is then forwarded to theidentified pipeline stage (i.e., a flow table or group table) (Block707).

FIG. 7B is a flowchart of the process of processing packets at thevirtual port. In one embodiment, the process is initiated in response toreceiving an OpenFlow packet injection message from a controller or asimilar source of a data packet to be inserted into a data flow (Block751). The virtual port can process each data packet using either anexternal source based process or an internal definition process. Ineither case, the virtual port can generate a data packet to be insertedinto a data flow as directed by the incoming message from the OpenFlowcontroller and define meta data for the data packets to be sent to theOpenFlow switch module (Block 753). The meta data can be determinedbased on information defined in the incoming message (external sourcebased process) or can be determined by the virtual port that the messageis directed to (internal definition process). After the data packet andmeta data have been generated based on the external source based processor the internal definition process, then the data packet and meta dataare forwarded to the OpenFlow switch module (Block 755).

Tagged Packet De-Multiplexing Process

The de-multiplexing or removal and processing method is a processimplemented in a destination or egress OpenFlow switch. Thede-multiplexing process enables the monitoring of the OpenFlow data flowalong its path up to the destination OpenFlow switch. Any supportingOpenFlow switch that identifies the monitored data packets, such as OAMpackets, is referred to herein as an egress OpenFlow switch. At theegress OpenFlow switch two flow table entries can be defined: (1) firstflow table entry defines criteria for identifying the tagged datapackets and defines their treatment, and (2) a second flow table entrydefines the treatment of the other data packets. The treatment of thetagged packets can be encoded by either a specific OpenFlow action orcan be expressed by sending the tagged packet to a well defined virtualport. In this latter case, the sending of the tagged packet to a virtualport either triggers an OpenFlow control message that encodesinformation related to the tagged packet, or relays the tagged packet toan specific switch module. The control message with the encodedinformation is sent to the OpenFlow controller to enable OAM functions.The two alternative processes for handling the tagged packets arefurther discussed below.

Switch Local Termination Process

In this embodiment of de-multiplexing the tagged data packets, thetagged data packets or frames are forwarded to a non-OpenFlow switchmodule, which is separate from the OpenFlow switch module and pipelineprocess. The non-OpenFlow switch module and the OpenFlow switch modulecan communicate with each other through a virtual port. The non-OpenFlowswitch module can pass meta data to the OpenFlow switch module. Thisswitch local termination process specifies that the OpenFlow switchmodule is able to pass meta data through the virtual port to the otherswitch modules. If no non-OpenFlow switch module that is able to processthe meta data is available, then the virtual port is able to suppressthe meta data, i.e., drop it without processing it.

Controller Targeted Process

In this embodiment of de-multiplexing the tagged data packets, thetagged data packets are relayed (i.e., forwarded) to the controller. ThePacket In message can be used to implement this feature without anymodification. However, the Packet In message does not pass all meta dataof a data packet to the controller, as the message carries only theincoming port (physical and/or virtual) and the table ID. Therefore thefollowing additional fields to the Packet In message are defined tosupport this controller targeted process by adding: (1) a GROUP/FLOWTABLE selection flag indicating the data packet is received afterprocessing by a flow table or by the group table. If thisGROUP/FLOWTABLE flag is set to 0, then the table_id field carries theindex of the flow table. Otherwise, the table_id must be set to 0 by thePIL of the OpenFlow switch module and should be omitted duringprocessing by the controller; (2) a metadata field, carrying the valueof the meta data field used during packet processing; (3) a Group IDfield that defines the identifier of the executed group table entry. Itcarries valid information if the GROUP/FLOW TABLE selection flag is setto 1. Otherwise, this field must be set to 0 and should be ignored bythe controller.

FIG. 8 is a flowchart of one embodiment of the de-multiplexing process.In one embodiment, the process is initiated in response to receiving anOpenFlow data packet at an OpenFlow switch module (Block 801). The datapacket is initially processed by the PIL module to match on the identityof the packet as a monitored (e.g., OAM packet) by checking a designatedfield of the data packet for a designated value that identifies thepacket as a monitored data packet (Block 803). The header or meta dataof the received packet can be used for identifying the packet as amonitored packet, an entire matching structure or any combinationthereof can also be utilized. In one embodiment, a virtual port thatreceived the data packet can modify the meta data to identify the datapacket as a monitored data packet. As a separate or combined step, thedata packet can be matched to determine whether the data packet is to beforwarded to a non-OpenFlow switch module or to an OpenFlow controller(Block 805). This can be encoded in the meta data or header of the datapacket. The data packet can be forwarded to the non-OpenFlow switchmodule to be processed when for example the data packet is an OAM packetgenerated and monitored by an OAM module separate from the OpenFlowcontroller. The data packet can be sent to the OpenFlow controller usinga control message to provide the entire data packet including the metadata when for example the data packet is an OAM packet and the OAMmodule is a part of the OpenFlow controller.

Example 1 Ethernet Packet Flow

This section gives an example use of an embodiment of the invention asapplied to frame identification, and configuring frame injection andde-multiplexing of OAM frames for an Ethernet flow.

Identification

In the first example Ethernet flows are deployed, i.e., only theEthernet header fields are utilized for matching and handling the datapackets, including the source and destination MAC address, and VLAN tagfields. There are no restrictions on the payload of the Ethernet packet.

The DL_TYPE of the matching structure, which defines the Ethertype fieldof an Ethernet packet, will be wildcarded. According to this exampleembodiment of the invention, this DL_TYPE field is selected todistinguish data packets. To select an appropriate value from theavailable domain (16-bits), one non-allocated Ethertype value can beselected. For example, a value can be selected that does not collidewith the allocated Ethertype values defined by IANA.

At the ingress side of the monitored flow, the following configurationis set. Only a single matching table is used. To inject the OAM frames,the packet headers are the same as for the service packets, except theEthertype, which is set to OAM (e.g. 0xD001). The matching rule isconfigured as: the Ethernet dst is the real destination address, whileall other fields are wildcarded. The action is to send to the next tableor output port.

At the egress side, a single table is used with two flow entries. Thefirst flow entry is for the OAM traffic. Matching is set as: Ethernetdst=the real destination address, Ethertype=OAM (e.g. 0xD001), all otherfields are wildcarded. Rule priority=101. Action=send to OAM port.

The second flow entry is for the service traffic. Matching is: Ethernetdst=real destination address, all other fields are wildcarded. Rulepriority=100. Action=send to next table or output port.

Example 2 MPLS Packet Flow

This section gives an example use of an embodiment of the invention onframe identification, and on configuring frame injection andde-multiplexing of OAM frames for an MPLS flow.

Identification

In the second example MPLS flows are considered and the following flowmatching entries are used during forwarding. The Ethernet fields may ormay not be set, but Ethertype is set to either 8847h or 8848h. The MPLSlabel matching field is set to a valid label value (between 16 and1048576). All other matching fields will not be considered duringmatching according to the OpenFlow 1.1 standard. Then a second label isused for packet exceptions. The OAM packets can be identified e.g. bysetting the second label with a value from 0-15 that is not specified byother standards.

At the ingress side, a single table is used with one flow entry. Toinject the OAM frames, the packet headers are the same as for theservice packets, except an additional MPLS header is used, with the OAM(e.g. 10) label. The flow table entry is configured as matching:Ethertype=0X8847, MPLS=given_label, all other fields are wildcarded.Action=push given_label and send to next table or output port.

At the egress side, two tables are used. The first table contains asingle flow entry, for both the monitored and the monitoring packets.The matching is set to the given_label, all other fields are wildcarded.The action is to remove the label and goto the second table. The secondtable contains two entries. The first one is for the monitoring packet,with a matching Ethertype=0x8847, MPLS=OAM (e.g. 10), all other fieldsare wildcarded. Priority: 101. Action: send to OAM port. The secondentry is for the monitored traffic, with matching set to Metadata=givenlabel, all other fields are wildcarded. Priority=100. Action=send tonext table or output port.

Example 3 IP Packet Flow

This section gives an example use of an embodiment the invention forframe identification, configuring frame injection and injection of OAMframes into an IPv4 flow.

Identification

In the case of an IP flow, the Ethernet fields may or may not be set,but the Ethertype is set to 0800h. The IP header fields are considered,like source and destination IP address and there are no restrictions onthe payload of the IP packet. Then the Protocol of the IP matchingstructure, which reflects to the next encapsulated protocol of an IPpacket, will be wildcarded. According to one example realization of thisinvention, this field will be selected to distinguish certain packets.

At the ingress side a single table is used. To inject the OAM frames,the packet headers are the same as for the service packets, except theIPv4_proto field, which is set to a new OAM (e.g. 250) type. Thematching of the flow entry is set to EtherTpye=0800, IP destination:given destination address, all other fields=wildcarded. The Action is tosend to next table or output port.

At the egress side one tables is used, with two entries. The first flowentry is for the OAM traffic. Matching is: Ethertype=0800, IPdestination: given destination address, IPv4_proto: OAM (e.g. 250), allother fields are wildcarded. Rule priority=101. Action=send to OAM port.The second flow entry is for the service traffic. Matching is:EtherTpye=0800, IP destination=given destination address, all otherfields are wildcarded. Rule priority=100. Action=send to next table oroutput port.

The embodiments of the invention, describe an extension to the OpenFlowswitch operation that allows the injection and de-multiplexing ofcertain data packets (tagged frames) into and/or from a data packetflow. Such configuration changes affect only the data switches involvedin the data injection or removal processes and does not necessitate anyconfiguration changes to any intermediate nodes. Thus, in anyintermediate node the same forwarding entry will be applied on both theregular data packets and the tagged frames. This feature ensures fatesharing for data packets inserted and monitored in a data flow.

The embodiments of the invention, enable easy and flexible deployment ofOAM tools in an OpenFlow domain as they provide not only fate sharingfor monitored data packets, but the embodiments also present mechanismsto forward the OAM packet to/from the monitoring points, regardless ofwhether the mechanisms are implemented at the switch or at thecontroller.

It is to be understood that the above description is intended to beillustrative and not restrictive. Many other embodiments will beapparent to those of skill in the art upon reading and understanding theabove description. The scope of the invention should, therefore, bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

1. A method implemented by a network element to monitor OpenFlow dataflows and enable operations, administration and management (OAM)functionality in OpenFlow, the method to insert OpenFlow OAM packetsinto an OpenFlow data flow to monitor the OpenFlow data flow, whereininserted OpenFlow OAM packets have fate sharing with data packets in theOpenFlow data flow, the method comprising the steps of: receiving by thenetwork element the OpenFlow OAM packets from a source through a port ofthe network element; matching by an OpenFlow switch module using amatching structure of OpenFlow data packets received by the networkelement to identify the OpenFlow OAM packets; and forwarding theidentified OpenFlow OAM packets to a flow table or group table of theOpenFlow switch module to aggregate the OpenFlow OAM packets with acorresponding OpenFlow data flow.
 2. The method of claim 1, furthercomprising the step of: updating meta data of the OpenFlow OAM packet bya virtual port of the network element using meta data defined by thesource.
 3. The method of claim 1, further comprising the step of:updating meta data of the OpenFlow OAM packet by a virtual port of thenetwork element using meta data defined by the virtual port.
 4. Themethod of claim 1, wherein the OpenFlow OAM packets are received with anOpenFlow packet injection message defining an inject packet action, themethod further comprising the step of: executing the inject packetaction by the OpenFlow switch module to inject the OpenFlow OAM packetinto the OpenFlow data flow.
 5. The method of claim 1, wherein thenetwork element de-multiplexes the OpenFlow OAM packets with an egressmethod comprising the step of: forwarding, by the OpenFlow switchmodule, the OpenFlow OAM packets to a switch module of the networkelement for OAM processing.
 6. The method of claim 1, wherein thenetwork element de-multiplexes the OpenFlow OAM packets with an egressmethod comprising the step of: forwarding, by the OpenFlow switchmodule, the OpenFlow OAM packets to an OpenFlow controller using anOpenFlow control message.
 7. A network element to monitor OpenFlow dataflows and enable operations, administration and management (OAM)functionality in OpenFlow, the network element to insert OpenFlow OAMpackets into an OpenFlow data flow to monitor the OpenFlow data flowwherein inserted OpenFlow OAM packets have fate sharing with datapackets in the OpenFlow data flow, the network element comprising: anincoming physical port to receive OpenFlow data packets from a sourcenode over a first network connection; an outgoing physical port totransmit OpenFlow data packets to a destination node over a secondnetwork connection; a network processor connected to the incomingphysical port and the outgoing physical port, the network processorexecuting an OpenFlow switch module, the OpenFlow switch module to matcha matching structure in OpenFlow data packets to identify the OpenFlowOAM packets, to forward the identified OpenFlow OAM packets to a flowtable or group table of the OpenFlow switch module to aggregate theOpenFlow OAM packets with a corresponding OpenFlow data flow, and toforward the OpenFlow data flow to the destination node through theoutgoing physical port.
 8. The network element of claim 7, furthercomprising: a virtual port executed by the network processor to updatemeta data of the OpenFlow OAM packet using meta data defined by thesource.
 9. The network element of claim 7, further comprising: a virtualport executed by the network processor to update meta data of theOpenFlow OAM packet using meta data defined by the virtual port.
 10. Thenetwork element of claim 7, the OpenFlow OAM packets are received withan OpenFlow packet injection message defining an inject packet action,the OpenFlow switch module executes the inject packet action to injectthe OpenFlow OAM packet into the OpenFlow data flow.
 11. The networkelement of claim 7, wherein the OpenFlow switch module de-multiplexesthe OpenFlow OAM packets with an egress method that forwards theOpenFlow OAM packets to a switch module of the network element for OAMprocessing.
 12. The network element of claim 7, wherein the OpenFlowswitch module de-multiplexes the OpenFlow OAM packets with an egressmethod forwards the OpenFlow OAM packets to an OpenFlow controller usingan OpenFlow control message.